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AMENDMENTS TO THE CLAIMS 

1.-7. (Canceled) 

8. (Canceled) 

9. (Currently amended) [[The]] A method of claim 8 for enabling personal area 
networking on a Bluetooth device, the method comprising: 

controlling state of a device control block (DCB), wherein controlling the state of 

the DCB comprises: 

when the Bluetooth device is added, causing the DCB to enter an idle state; 

from the idle state, in response to a halt request event, entering a halt wait state; 

from the idle state, in response to a connection control block (CCB) established 
event, causing the DCB to enter a busy state; 

from the busy state, in response to a CCB teardown event reducing to zero a count 
of CCBs associated with the DCB, causing the DCB to return to the idle state; 

from the busy state, in response to a CCB established event, causing the DCB to 
remain in the busy state; 

from the busy state, in response to a halt request event, causing the DCB to enter the 
halt wait state; 

from the halt wait state, in response to a CCB teardown event reducing to zero a 
count of CCBs associated with the DCB, causing the DCB to enter a halting state; 

from the halt wait state, in response to a CCB teardown failed event, causing the 
DCB to enter a zombie state; 

from the halting state, in response to a halt complete event, causing the DCB to 
enter a halted state; and 

from the halted state, in response to a device remove event, causing the DCB to . 
enter a terminal state. 
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10. (Canceled) 

1 1 . (Currently amended) [[The]] A method of claim 10 for controlling a connection 
on a Bluetooth Personal Area Network (PAN) device, the method comprising: 

controlling state of a Logical Link Control Adaptation Protocol (L2CAP) connection 

control block (CCB), wherein controlling the state of the L2CAP CCB comprises: 

initially causing the L2CAP CCB to enter a closed state; 

from the closed state, in response to an open initialize event, causing the 
L2CAP CCB to enter an opening state; 

from the opening state, in response to an open fail event, causing the L2CAP 
CCB to enter a closing state; 

from the opening state, in response to a close initialize event, causing the 
L2CAP CCB to enter a close wait state; 

from the opening state, in response to an open success state, causing the 
L2CAP 

CCB to enter an open state; 

from the closing state, in response to a close success event, having the L2CAP 
CCB enter a terminal state; 

from the closing state, in response to a close fail event, having the L2CAP 
CCB enter a zombie state; 

from the close wait state, in response to a close issue event, having the L2CAP 
CCB enter the closing state; 

from the open state, in response to the close initialize event, having the L2CAP 
CCB enter the close wait state; 

from the open state, in response to the open fail event, having the L2CAP CCB 
enter the close wait state; and 

from the open state, in response to an open finalize event, having the L2CAP 
CCB remain in the open state ; and 

controlling state of a Bluetooth Network Encapsulation Protocol (BNEP) CCB . 
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12. (Currently amended) [[The]] Ajnethod of claim 10 for controlling a 
connection on a Bluetooth Personal Area Network (PAN) device, the method comprising: 

controlling state of a Logical Link Control Adaptation Protocol (L2CAP) connection 

control block (CCB); and 

controlling state of a Bluetooth Network Encapsulation Protocol (BNEP) CCB, 

wherein controlling the state of the BNEP CCB comprises: 

initially causing the BNEP CCB to enter a closed state; 

from the closed state, in response to a connect request passive event, causing 
the BNEP CCB to enter an opening passive state; 

from the closed state, in response to a connect request active event, causing 
the BNEP CCB to enter an opening active state; 

from the opening passive state, in response to a successful connect complete 
event, causing the BNEP CCB to enter an open state; 

from the opening passive state, in response to a disconnect request event, 
causing the BNEP CCB to enter the closed state; 

from the opening active state, in response to a successful connect complete event, 
causing the BNEP CCB to enter an open state; 

from the opening active state, in response to a disconnect request event, causing the 
BNEP CCB to enter the closed state, and 

from the open state, in response to a disconnect request event, causing the BNEP 
CCB to enter the closed state. 

13. (Canceled) 

14. (Currently amended) [[The]] A_system of claim 13 wh e r e in for enabling personal 
area networking on a Bluetooth device, the system comprising: 

a finite state machine associated with a device control block (DCB\ the finite state 

machine associated with the DCB compris e s comprising : 
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a plurality of states, further comprising an idle state, a busy state, a halt wait state, a 
zombie state, a halting state, and a halted state; 

a plurality of transition events, further comprising a device add event, a 
connection control block (CCB) teardown event, a CCB established event, a halt request 
event, a CCB teardown failed event, a halt complete event, and a device remove event; 
and 

a plurality of transitions, further comprising: 

an initial transition to the idle state, associated with the device add event; 

a transition from the idle state to the halt wait state, associated with the 
halt request event; 

a transition from the idle state to the busy state, associated with the 
CCB established event; 

a transition from the busy state to the idle state, associated with the 
CCB teardown event and a zero CCB count; 

a transition from the busy state to the busy state, associated with the 
CCB established event; 

a transition from the busy state to the halt wait state, associated with 
the halt request event; 

a transition from the halt wait state to the zombie state, associated 
with the CCB teardown failed event; 

a transition from the halt wait state to the halting state, associated with 
the CCB teardown event and a zero CCB count; 

a transition from the halting state to the halted state, associated with 
the halt complete event; and 

a transition from the halted state to a terminal state, associated with 
the device remove event. 

15. (Canceled) 
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16. (Currently amended) [[The]] A system of claim 15 wh e r e in th e finite stat e 
machin e associat e d with th e L2CAP CCB comprises for controlling a connection on a 
Bluetooth Personal Area Network (PAN) device, the system comprising: 

a finite state machine associated with a Logical Link Control Adaptation Protocol 

(L2CAP) connection control block (CCB), the finite state machine comprising : 

a plurality of states, further comprising a closed state, an opening state, a closing 

state, a close wait state, an open state, and a zombie state; 

a plurality of transition events, further comprising a connect request event, an 

open initialize event, a close success event, a close issue event, a close initialize event, 

an 

open fail event, an open success event, a close fail event, and an open finalize event; 
and 

a plurality of transitions, further comprising: 

a transition from an initial state to the closed state, associated with the 
connect request event and a connection count not exceeding a maximum; 

a transition from the closed state to the opening state, associated with the 
open initialize event; 

a transition from the opening state to the closing state, associated with the 
open fail event; 

a transition from the opening state to the close wait state, associated with 
the close initialize event; 

a transition from the opening state to the open state, associated with the 
open success event; 

a transition from the closing state to a terminal state, associated with the 
close success event; 

a transition from the closing state to the zombie state, associated with the 
close fail event; 

a transition from the close wait state to the closing state, associated with 
the close issue event; 
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a transition from the open state to the close wait state, associated with the 
close initialize event; 

a transition from the open state to the close wait state, associated with the 
open fail event; and 

a transition from the open state to the open state, associated with the open 
finalize event ; and 

a finite state machine associated with a Bluetooth Network Encapsulation Protocol 
(BNEP) CCB . 

17. (Currently amended) The system of claim [[15]] 16 wherein the finite state 
machine associated with the BNEP CCB comprises: 

a plurality of states, further comprising a closed state, an opening passive state, an 1 0 
opening active state, and an open state; 

a plurality of transition events, further comprising a connect request passive event, a 
connect request active event, a disconnect request event, and a connect complete event; and 

a plurality of transitions, further comprising: 

a transition from an initial state to the closed state; 

a transition from the closed state to the opening passive state, associated with the 
connect request passive event; 

a transition from the closed state to the opening active state, associated with the 
connect request active event; 

a transition from the opening passive state to the open state, associated with the 
connect complete event; 

a transition from the opening passive state to the closed state, associated with the 
disconnect request event; 

a transition from the opening active state to the open state, associated with the 
connect complete event; 

a transition from the opening active state to the closed state, associated with 
the disconnect request event; and 
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a transition from the open state to the closed state, associated with the 
disconnect request event. 

18. (Original) The system of claim 17 wherein the disconnect request event is 
due to one of (a) a peer, (b) a local user, and (c) a connection failure. 

19. (Currently amended) A method for setting and advertising multiple Personal 
Area Network (PAN) profile roles in a Bluetooth device, the method comprising: 

operating as a Personal Area Network User (PANU) PAW while advertising a PANU 
role and a Group Ad-hoc Network (GN) GH service; 

if a remote device attempts to connect to the GN service, switching to providing the 
GN service, and removing a PANU Service Discovery Protocol (SDP) S DP service record; 

if no remote user of the GN service remains connected, switching back to providing 
the PANU role, readvertising the PANU role, and retaining a GN SDP service record; 

if a local user manually creates a bridge between the Bluetooth device and another 
network connection, switching to providing a NAP service, and removing the PANU SDP 
record and the GN SDP record; and 

if the local user manually deletes the bridge, removing a NAP SDP record, 
switching back to and readvertising the PANU role, and reinstating the PANU SDP record 
and the GN SDP record. 

20. (Currently amended) A system having a finite state machine for setting and 
advertising multiple Bluetooth Personal Area Network (PAN) PAN profile roles, the system 
comprising: 

a Personal Area Network User (PANU) PANU role state, associated with advertising of 
both a PANU profile and a Group Ad-hoc Network (GN) GN service; 
a GN role state; 

a transition from the PANU role state to the GN role state, associated with a connection to 
the GN service by a remote Bluetooth device; 
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a transition from the GN role state to the PANU role state, associated with all users of the 
GN service disconnecting from the GN service; 

a Network Access Point (NAP) NAP role state; 

a transition to the NAP role state associated with a creation of a bridge to another network 
connection; and 

a transition from the NAP role state to the PANU role state, associated with a deletion of 
the bridge. 

21. (Currently amended) A computer-readable medium having computer-executable 
instructions implementing a method for setting and advertising multiple PAN profile roles in a 
Bluetooth device, the method comprising: 

operating as a Personal Area Network User (PANU) PANU while advertising a PANU 
role and a Group Ad-hoc Network (GN) GN service; 

if a remote device attempts to connect to the GN service, switching to providing the GN 
service, and removing a PANU Service Discovery Protocol (SDP) SP-fi service record; 

if no remote user of the GN service remains connected, switching back to providing the 
PANU role, readvertising the PANU role, and retaining a GN SDP service record; 

if a local user manually creates a bridge between the Bluetooth device and another network 
connection, switching to providing a NAP service, and removing the PANU SDP record and the 
GN SDP record; and 

if the local user manually deletes the bridge, removing a NAP SDP record, 
switching back to and readvertising the PANU role, and reinstating the PANU SDP record and 
the GN SDP record. 
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